Remove group_sum_starttime due to its unclear purpose and predominantly
zero values.

'select count(*) from mxq_group where group_sum_starttime=0'
+----------+
| count(*) |
+----------+
|   539223 |
+----------+
'select count(*) from mxq_group where group_sum_starttime!=0'
+----------+
| count(*) |
+----------+
|    11014 |
+----------+
'select distinct(group_sum_starttime) from mxq_group limit 10'
+---------------------+
| group_sum_starttime |
+---------------------+
|                   0 |
|         62509173560 |
|        682762450608 |
|         50573290960 |
|        126435008048 |
|        328732081280 |
|         75859753168 |
|         75859750064 |
|       1770065450784 |
|         75861674832 |
+---------------------+

The current error handling in mx_mysql logs errors multiple times in
different forms due to nested functions and the mapping of MySQL error
codes to system error codes. This leads to unclear semantics and
complicated code.

The current error handling return the same error in errno and in the
function return value which results in uneeded accesses to errno

This commit introduces the following changes:

*   MySQL error strings are captured but not logged by the module. A new
    function mx_mysql_error() is provided for the caller to retrieve the
    latest error string.
*   System error codes are returned as the function value, but errno is
    not set.
*   It is now the caller's responsibility to log errors.

This change reduces the object size of mx_mysql by 28%. Future commits
will address error return values that do not relate to MySQL error
strings.

The assertion

    mx_assert_return_minus_errno((unsigned int)(int)error == error, ERANGE);

does not function as intended, as the conditional expression is
optimized away to true by gcc with -O1 and up [1].

While there are alternatives to detect values outside of the range
[0..-INT_MIN] that could not be negated into the range [INT_MIN..0], the
check appears to be unnecessary.  All callers use the MySQL error numbe
for comparison with constants.

This commit removes the helper functions `mx__mysql_errno()` and
`mx__mysql_stmt_errno()` and replaces them with native MySQL calls.

[1]: https://godbolt.org/z/1ajK384Ge

If the file is not readable, the warning is now saved to be retrievable
by the caller instead of being emitted. The warning text has been
shortened from:

    MySQL ignoring defaults file: euidaccess("/etc/mxq/mysql_ro.cnfX", R_OK) failed: No such file or directory
    MySQL falling back to mysql default config search path.

to

    /etc/mxq/mysql_ro.cnfX: No such file or directory - falling back to mysql default config search path

`mx_mysql` no longer delivers errors in `errno`, so this commit changes
the callers to not use `errno` after a failed call to a `mx_mysql` function,
but only the return value. The "%m" format for getting the error message
is replaced with "%s" in conjunction with `mx_mysql_error()`.

This commit also removes some redundant error logging from nested
function calls.

Currently, `mx_mysql` uses its own assert macros, which log the failed
condition and then return an error value to the caller (via return
status and via errno).

This commit changes the approach to use the standard `assert()` to abort
right away in case of failures, as all `assert()` failures are serious
coding errors. This simplifies the coding for the callers.

Following the last commit, the bind functions and macros of `mx_mysql`
can no longer return a failure status. This commit changes them to void
functions, simplifying the callers.

When mxqkill is used against a running job, it needs to communicate the
fact that the job should be aborted to the daemon handling it. This
commit adds a boolean (TINYINT) column `job_cancelled` to `mxq_job` for
this purpose.

Other options such as overloading `job_status`, utilizing a bit of
job_flags, and using MySQL BIT or SET data types were considered but
discarded to avoid code complexity.

To cancel a single job, this commit introduces the following changes:

* The owner uid is verified in advance to avoid a join withi `mxq_group`
  during a later update statement. This is because the join during
  update doesn't work well with the triggers that want to modify
  `mxq_group.. By avoiding this, we can later dispose of the CANCELLING
  state, which is also just a workaround for this problem.

* job_cancelled is set to true for the job, regardless of job_status.

Transitions of job_status will be handled by following commits.

Use the `cancel_job()`function introduced in the previous commit to
cancel a single job.

This commit introduces periodic checks for the job_cancelled flags for
the jobs run by this daemon. If a cancellation of the job was requested,
the job is killed using the existing mechanism.

This commit removes the -> `CANCELLED` housekeeping from the
`mx_update_job` trigger as we no longer set the state to `CANCELLED` by
code.

Instead, a new trigger is added, which transitions a job from `INQ` to
`CANCELLED` when the `job_cancelled` flag is set.

For jobs that are `RUNNING`, the `job_cancelled` flag needs to be
handled by the daemon, which kills the job. Note that the job will
transition into `KILLED` not into `CANCELLED`.

This approach eliminates the need for any code for jobs getting killed
in the `LOADED` or `ASSIGNED` states, as these will either transition
into `RUNNING` or - in very exceptional cases - back into INQ.

This commit removes the obsolete job status `CANCELLING`. It also
removes the `* -> NOT IN [ CANCELLING(989) | CANCELLED(990) ]` trigger,
which would reduce to `* -> CANCELLED(990)`, but the only transition to
`CANCELLED` is from `INQ` where there are no job run time statistics
that need to be accumulated into mxq_group.